-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow Implicit RID Opt Out + Don't Infer RID for non EXE Type Projects #28628
Conversation
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
There is another possible solution that might help some other scenarios (like the exe-depends-on-exe we talked about): stop |
@@ -65,6 +65,7 @@ Copyright (c) .NET Foundation. All rights reserved. | |||
( | |||
'$(RuntimeIdentifier)' == '' and | |||
'$(RuntimeIdentifiers)' == '' and | |||
'$(OutputType)' == 'Exe' and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to also add an explicit do-not-infer-RID property here? Since it's caused trouble once, it would be nice to be able to offer a solution to users who hit another related problem without requiring servicing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You probably want to use _IsExecutable
or HasRuntimeOutput
instead of OutputType
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Making the change, but for my own understanding: may you please explain why either of those is better than OutputType
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The OutputType can also be WinExe
, which these properties take into account.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to add a test for the failing scenario?
@@ -65,6 +65,7 @@ Copyright (c) .NET Foundation. All rights reserved. | |||
( | |||
'$(RuntimeIdentifier)' == '' and | |||
'$(RuntimeIdentifiers)' == '' and | |||
'$(OutputType)' == 'Exe' and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You probably want to use _IsExecutable
or HasRuntimeOutput
instead of OutputType
here.
src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.RuntimeIdentifierInference.targets
Outdated
Show resolved
Hide resolved
…imeIdentifierInference.targets Co-authored-by: Rainer Sigwald <[email protected]>
…nto nagilson-exe-rids
src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.RuntimeIdentifierInference.targets
Outdated
Show resolved
Hide resolved
…s Exe Co-authored-by: Daniel Plaisted <[email protected]>
cc @baronfel @richlander to potentially comment on how bad or not bad it would be if we removed implicit RIDs for 7.0, in case there is objection to adding this fix and tactics would rather pull the feature for now. We're bringing this to tactics because we found a scenario where this broke VS publishing; VS publishing has their own RID logic. This fixed it but can't be 100% sure there isn't any additional stuff we haven't thought of. Preferably, we keep it. |
src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.RuntimeIdentifierInference.targets
Outdated
Show resolved
Hide resolved
src/Tests/Microsoft.NET.Publish.Tests/GivenThatWeWantToPublishASingleFileLibrary.cs
Show resolved
Hide resolved
src/Tests/Microsoft.NET.Publish.Tests/GivenThatWeWantToPublishASingleFileLibrary.cs
Show resolved
Hide resolved
Initial Feature was added in 2020 but not documented here: dotnet/sdk#10449 We've added implicit RIDs here: dotnet/sdk#26143 And we've added interaction to toggle implicit RIDs off with UCR here: dotnet/sdk#28628 And we added the shorthand for ucr here: dotnet/sdk#27971 Needs to be duplicated for `dotnet publish` as well.
Description
UseCurrentRuntimeIdentifier
property to opt out of this feature (Implicit RIDS) in case someone doesn't want itCreate a .NET Core project (e,g, Winforms APP)
In same solution, add a Class Library and set it as a project reference to the main project (created in step1)
Navigate to ClickOnce publish wizard, and set all as default
Navigate to Configurations wizard and set it to Framework-Dependent, SingleFile, x86
Publish and see failure. Only fails in VS. Also, if you set the properties anywhere besides VS, it won't fail.
Before:
After:
Why?
PublishSingleFile (PSF) is not supposed to work if you don't set a RID, but it works if you set a RID in the top-level project but then don't flow the RID to the project references.
AppendsRuntimeIdentifierToOutputPath is set to true even with there is no rid in a library if the top level project had a rid, so the library is ridless but tries to append it's nonexistent rid to the output path which used to be OK
We tried to infer a RID because PSF generally requires a RID to exist but the check for the RID doesn't run in PrepareForPublish for Non-Exe projects.
When VS Injects their own publishing properties in the publishing wizard the pathing gets mixed up.
So, we can solve this by only doing that inference for Exe OutputTypes since PSF doesn't require a RID in subprojects. Rainer confirmed with me that it fixed this scenario. We need to take it to tactics now most likely.
cc @rainersigwald @dsplaisted
Customer Impact
Will allow customers to correctly publish libraries in the VS Publishing wizard but also keep the feature of not having to specify a RID when building or publishing selfcontained and friends.
Regression
This is a new feature so not a regression.
Risk
Low because it only lowers the scope of a newer feature and allows opting out of that feature instead of doing it everytime.
But there is a chance it might break something else we haven't thought of. So far, we didn't find anything else.
Testing
See the above Before and after screenshot.